This chapter describes how to use the Address Resolution Protocol (ARP), Inverse Address Resolution Protocol (Inverse ARP), and ARP Over ATM on your router. It includes the following sections:
| Note: | If the device's software load does not contain Asynchronous Transfer Mode (ATM), ATM-related commands are not valid and are not displayed at the ARP configuration and console prompts. |
The ARP Protocol is a low-level protocol that dynamically maps network layer addresses to ATM addresses or physical medium access control (MAC) addresses. Given only the network layer address of the destination system, ARP locates the ATM address or MAC address of the destination host within the same network segment.
For example, a router receives an IP packet destined for a host connected to one of its LANs. The packet contains only a 32-bit IP destination address. To construct the data link layer header, a router acquires the physical MAC address of the destination host. Then, the router maps that address to the 32-bit IP address. This function is called address resolution. Figure 49 illustrates how ARP works.
Figure 49. ARP Address Resolution Broadcast
When a router translates a network layer address to a physical address, the router accesses the ARP (translation) cache. The ARP cache contains the physical MAC address that corresponds to that network layer address. If the address is missing, the router broadcasts an ARP request to all hosts on the attached network segment to locate the correct physical MAC address. The node with the correct physical MAC address responds to the router. The router then sends the packet to the node and enters the physical MAC address into the translation cache for future use.
RFC 1577, Classical IP & ARP over ATM, extends the ARP protocol with a different packet format and with the addition of an entity known as the ARP Server as described in "Classical IP Components".
Inverse ARP, described in RFC 1293/2390, was created for Frame Relay networks. This protocol defines a method for routers on a Frame Relay network to learn the protocol addresses of other routers in a way that very efficiently reduces traffic by eliminating the need to use broadcast ARP packets for address resolution. Inverse ARP discovers a protocol address by sending Inverse ARP request packets to the hardware address (for Frame Relay circuits the circuit identifier is the Frame Relay equivalent of a hardware address; for ATM, an ATM address is exchanged), as soon as the circuit becomes active. The remote router responds with its protocol address and the resulting mapping is stored in the ARP cache.
In ATM, the inverse ARP packet has been extended to handle the variable-sized ATM addresses of the source and destination. Addresses learned by inverse ARP are aged out in the same way as those learned by ARP.
The protocol address-to-hardware address entries learned by Inverse ARP do not time out when the ARP refresh timer expires. The mappings do not age at all except when the Frame Relay circuit goes down. This means that the router does not need to transmit any ARP broadcasts to update the ARP cache. However, the router permits updates to an entry when the other (remote) router changes its protocol address.
Support for both ARP and Inverse ARP greatly enhances the router's interoperability with other vendors' routers over Frame Relay for dynamic mapping of protocol and hardware addresses. If other Frame Relay-attached routers support Inverse ARP, then the mappings are dynamically learned as described above. If the attached routers do not support Inverse ARP but support "traditional" ARP on Frame Relay, then the mappings still could be learned dynamically using ARP exchanges (see Figure 49).
If needed, you can manually configure the protocol addresses of other routers using the Frame Relay configuration command add protocol-address. For additional information, see the chapter Configuring and Monitoring Frame Relay Interfaces in Nways Multiprotocol Access Services Software User's Guide.
The Internet Engineering Task Force (IETF) has standardized its solution for sending IP traffic over an ATM interface in RFC 1577, "Classical IP & ARP over ATM". This document, created by the IP over ATM working group of the IETF, strives to keep the ATM infrastructure transparent to IP. Most applications that run today in a LAN or WAN environment will see no difference in function; however, their performance and throughput gains may be substantial, as described in "Advantages of Classical IP".
RFC 2225 is an extension to RFC 1577 that changes the client registration mechanism and allows for multiple ATM ARP servers. The 2216 supports both RFC 1577 and 2225 behaviors.
For additional information on Classical IP & ARP over ATM, and for illustrations showing logical and physical network configurations, refer to &swug;.
In Classical IP (CIP), IP stations are grouped in Logical IP Subnets (LIS). Classical IP servers and clients are defined to support these subnets similar to the way that LAN Emulation servers and clients are defined to LAN Emulation Services as described in the "Using and Configuring LAN Emulation Services (LES)" chapter of Nways Multiprotocol Access Services Software User's Guide.
For many configuration commands, you will be prompted to answer questions that are identical to those for LAN Emulation Clients and Servers. Questions that require ATM address ESIs and selectors, for example, will be asked in a similar manner whether you are configuring Classical IP or LAN Emulation.
Each of these configuration questions is based on the client definition. A client is defined as an interface number (ATM only) and an IP address.
In its simplest form, the IP client has no server and can talk only to those that contact its automatically-assigned ATM address. If PVCs have been assigned, then they will be operational.
For a more detailed description of ATM, refer to the "Using, Configuring, and Monitoring ATM" chapter in Nways Multiprotocol Access Services Software User's Guide.
Classical IP has several advantages over conventional IP:
Classical IP requires less framing bytes than, for example, LANs (which contain source and destination MAC addresses), so less of the bandwidth is used for overhead and more is used for data.
In a broadcast environment, ARP traffic can adversely affect all stations. In Classical IP, the ARP traffic affects only the ARP Server and the client requesting the information. All other stations on the subnet are unaffected by this traffic.
When IP is used over a shared medium such as token ring or Ethernet, frames transmitted between two stations preclude other stations on the same physical network from sending messages. This is true even when the traffic is nonbroadcast. In Classical IP, independent channels are established between hosts having the conversation. These channels can be established with traffic parameters that protect the conversation from being impacted by other conversations.
The same benefits of moves, adds, deletes, etc., described for LAN emulation over ATM also apply to the CIP Logical IP Subnet (LIS). Refer to "Using, Configuring, and Monitoring ATM" chapter in Nways Multiprotocol Access Services Software User's Guide.
Membership in a LIS is not based on physical location. Logically related stations may be grouped into the same LIS. The ease with which a client can register with the ARP Server makes additions and changes trivial. The deletion will occur naturally as the ARP Server ages its entries.
While all members of a LIS must support the Classical IP model, the 2216 can easily route between CIP Logical IP Subnets (LIS) and emulated LAN subnets. Some equipment may be more adept at CIP while other equipment may be more adept at LAN emulation. The flexibility of the 2216 allows you to place that equipment where it is most effective.
The Logical IP Subnet contains all of the properties of a normal IP subnet whether it is Ethernet, Token-Ring, or Frame Relay. However, because ATM is a Non-Broadcast Multiple Access (NBMA) network, the existing broadcast method for resolving addresses cannot be performed. To solve the addressing problem, RFC 1577 describes a registration/request procedure and introduces the notion of an ARP Server and ARP clients.
One ARP service is defined per LIS. The ARP service may be one ARP Server or several distributed ARP Servers per LIS. The service maintains the translation of IP addresses to ATM addresses. It allows CIP Clients to register by receiving incoming VCCs and querying the client for the appropriate information. The ARP service also responds to ATMARP requests for ATM addresses corresponding to IP addresses requested by the client. Finally, the ARP service manages and updates its tables through aging ARP entries and managing incoming VCCs.
The client is the entity that always places calls. A client, as it IMLs, will place a call to and register with an ARP Server. The call placed by the client to the server is called a control channel. When the client has traffic to transmit to another client on the LIS, the client sends an ARP request to the ARP Server with the target IP address. The server sends back either a reply (if the server has the information in its table) or a NAK (if no information is available). The client uses this ATM address to place a call to the target client (this call is referred to as a data channel). Once the call is established, IP datagrams may traverse the link at any time.
Within the CIP model, there are two forms of request/replies: ATM ARP request/replies (referred to as ARPs), and InATMARP request/replies. One could consider InATMARPs as gathering first-hand information. That is, InATMARP is used to query the other end of a VCC for its IP address and ATM address. InATMARP also informs the other end who it is (its IP address and ATM address). ATMARP could be considered surrogate information. A CIP client sends an ATMARP to the ARP Server to find the ATM address corresponding to the specified IP address. The Server replies with the requested information, or with a NAK if the information is not available. However, the RFC requires all clients and servers to respond to ARPs and InATMARPs with the appropriate response.
RFC 2225 clients register with the ARP Server by sending an ARP request with the source and target protocol addresses set to the same value. The registration process is completed successfully when the clients receive an ARP reply for this request.
For each LIS, the device can appear as a client only, or can appear as both a client and an ARP Server on that LIS. The device does not support an ARP Server only as this goes against the recommendation of RFC 1577 that each ARP Server should contain an IP address.
Refer to the Nways Multiprotocol Access Services Software User's Guide for additional information about ATM Virtual Interfaces.
Both the CIP client and ARP Server age their ARP entries. Once the timer for an ARP entry expires, that entry is deleted. If traffic is flowing when an ARP entry gets aged, that traffic will cease for a period until a new ARP entry is created. To avoid any interruption in service, the device provides an automatic refresh option. This option allows the client to transmit either an ARP request to the ARP Server or a positive InATMARP response only to the target client some time before the ARP entry expires. If the target replies, the timer of the ARP entry is reset. If the target does not, the entry is deleted. The ARP Server automatically sends out an InATMARP message before aging an entry in its table. The client and ARP Servers default to aging periods of 5 minutes and 20 minutes respectively. These times are configurable for each LIS (client or client/server pair).
Notes:
RFC 2225 clients are required to re-register with the ARP Server every 15 minutes by sending an ARP request for its own IP address. The refresh time is configurable, but RFC 2225 specifies that 15 minutes is the re-registration interval.
RFC 2225 servers are not required to refresh client entries using InARPs. It is the responsibility of the client to re-register. The default value for server auto-refresh remains Yes so that the server is compatible with RFC 1577 clients. If the LIS has only RFC 2225 clients, auto-refresh can be set to No on the servers.
IP addresses are key to IP routing. When configuring the device, the act of adding an IP address to an interface (ATM port), automatically creates a CIP client. The client is defined further by adding ATM ARP client information, but it is the adding of the IP address that creates the client.
Each server, since it contains an IP address, implicitly contains a client as well. When configuring the server, you must configure an IP address, automatically creating a client. The required databases are then created and maintained to service incoming requests.
The IP address configured does not necessarily imply that the device will act as a router. To act as a router, a higher level routing protocol such as OSPF must be configured. However, if the device is attached to multiple subnets, and if packets are sent to it from one subnet destined to a station on one of the other attached subnets, the device will forward that packet without having any routing protocol configured. Further, if a packet is sent to the device, but the destination of the packet is not the device, and the destination is on the same subnet as the source, the device will send an ICMP redirect message to the originator, and will forward the packet to the proper host.
Each client receives a unique ATM address. As described earlier, only NSAP addresses are supported. The End System Identifier (ESI) and the Selector can be chosen by the person configuring or it may be generated automatically during initialization time. If a device is configured as a client-only on a LIS, then configuring the ESI or Selector is not required (it is recommended that automatic generation be used). If a device is configured as a client/server pair, then it is strongly recommended that you do specify your own Selector, and if necessary, the ESI. (Note that the ESI will default to a burned-in 6-byte value that is unique.) A user will want to specify this information so that the specific ATM address comes up every time for that Server. Clients wishing to connect to this server can rely on the fact that the ATM address of the Server will not change.
If a server/client pair is configured for a specific LIS, then both the server and the client will use the same ATM address. The ATM addresses (ESI/Selector combination) for each CIP client should be unique.
A Virtual Channel Connection (VCC) is the lowest common denominator for data transmission. It can either be dynamically created in which case a VCC is a Switched Virtual Circuit (SVC), or it may be configured in the ATM Switch and end stations as a Permanent Virtual Circuit (PVC).
SVCs require a call setup or signalling protocol to establish the connection. Setting up an SVC is similar to placing a phone call. The user dials a phone number and waits for the phone to be answered before communicating to the answering party. If either end hangs up the phone, then the caller must redial the number before talking again. The same is true for ATM SVCs. The host sends out a setup message with a 20-byte ATM address (similar to a phone number), and waits for the other end to connect. Either host can hang-up the channel.
PVCs, on the other hand require no signalling protocol. Nor do they require matching levels of UNI. They are static, and are available to the host from initialization time until power down. The host does not need to take any actions to "set up" the connection. As such, PVCs are simpler and generally more reliable than SVCs.
The device's implementation of Classical IP supports both PVCs and SVCs. SVCs may be generated automatically through the address resolution process and subsequent call setup performed by the Classical IP code, or an SVC may be explicitly configured by the user. Automatic SVCs are brought up and torn down by the ARP subsystem as required for sending IP traffic. A configured SVC is brought up during initialization, and is kept up indefinitely. If the configured SVC does not connect, the device continues to retry the connection periodically until power is turned off.
PVCs and configured SVCs require no ARP Server definition. That is, a LIS could consist of hosts that were interconnected only by configured information. Optionally, the destination IP address of a configured PVC or SVC can be configured as well. If the IP address is not configured, InATMARP packets are used to determine what IP address sits at the opposite end of a VCC. For a network of any size, the amount of manual configuration would become prohibitive. Automatically generated SVCs drastically reduce the amount of configured information, and provide maximum flexibility for adding and moving hosts.
Automatically generated VCCs can only exist with the assistance of an ARP Server. Each client must be configured with the ARP Server's ATM address. Immediately after initialization, the client will attempt to connect to the ARP server. This connection is referred to as a control channel. The principal use of a control channel is for sending ATMARP and InATMARP requests and replies, although if the ARP Server is also a client, the control channel also can be used for sending IP data. Automatic VCCs generated to send data from one host to another are referred to as data channels.
The attributes of both control and data channels can be tailored to the user's needs. The CIP configuration of the device allows for configuration of the Peak Cell Rate, Sustained Cell Rate, maximum SDU sizes and other characteristics of the control and data channels set up by the device. A user also can choose to limit the cell rates of incoming calls to avoid the problems caused by mismatches in bandwidths of the various ATM attachments.
The simplicity of CIP is that very few configuration parameters are required. For a client-only, three pieces of information are required:
The IP address and subnet mask are required to give the client its unique IP identity so that it can send and receive IP datagrams. It also defines the subnet to which this CIP client belongs. The ATM address of the ARP Server is used by the client during initialization to establish a control channel with the ARP Server.
Multiple ARP Servers can be defined for a given LIS for backup purposes. If the primary ARP Server goes down, the client can switch to a backup ARP Server to avoid a single point of failure. The client will be able to switch back to its primary ARP Server as soon as the primary ARP Server resumes service. The first configured ARP Server ATM address will be chosen as the default primary ARP Server for a given LIS. You can change the primary ARP Server using the reorder command from the ARP Config> command prompt.
The configuration of the server is similarly simple. Essentially, the server needs to be defined with a fixed, well-known ATM address, and it needs to know which LIS it is serving. The server configuration requires the following:
The IP address and Subnet mask tell the server which LIS it is serving. The IP address also gives IP access to the server and routing function if desired (through the implicit client). Questions 2 and 3 are asked, among others, in the "add atm-client-configuration" Question 2 is required to enable the server function for that LIS. Question 3 is used to give the server a predictable ATM address.
Addresses are entered in two ways, depending on whether the address represents (1) an IP address, or (2) an ATM address, MAC address, or route descriptor, as follows:
IP addresses are entered in dotted decimal format, a four-byte field represented by four decimal numbers (0 to 255) separated by periods (.).
ATM addresses, MAC addresses, and route descriptors are entered as strings of hexadecimal characters with or without optional separator characters between bytes. Valid separator characters are dashes (-), periods (.), or colons (:).
This applies to addresses entered for ATM, LAN emulation, and Classical IP & ARP over ATM.
Example of IP Address:
01.255.01.00
Examples of ATM address, MAC address or route descriptor:
A1FF010203 or A1-FF-01-02-03 or A1.FF.01.02.03 or 39.84.0F.00.00.00.00.00.00.00.00.00.03.10.00.5A.00.DE.AD.C8 or A1:FF:01:02:03 or even A1-FF.01:0203
The ARP Server redundancy has two devices. One serves as the primary ARP server and the other serves as the backup to the primary. Classical IP Redundancy allows you to specify in your configuration which device will act as the primary server, and which device will act as the secondary server (backup server). In this type of redundancy, the primary server is configured to service and route for a given LIS. When the primary fails, the backup registers using the primary's ATM address and takes over as the ARP Server. It can also act as the redundant default IP gateway, thereby taking over as the server and the router for that LIS. So, when everything is operational, the primary has two IP addresses on the LIS (a client IP address and a gateway IP address), and the backup has a single client IP address on the LIS. When the primary fails, the primary will obviously cease to have any appearance on the LIS, and the backup will have two IP addresses on the LIS (its original client IP address, and its newly obtained redundancy default IP gateway address). The backup will also assume the role of the ARP Server for that LIS (by taking over the ATM address of the primary).
ARP Server redundancy configuration will give you the capability to control which device acts as primary, and which one acts as the secondary. This allows you to effectively balance the load on your ARP Servers while providing backup. For example, you may want a device to be the primary ARP Server for six LISs and to be the secondary for six other LISs. And you may want a second device to be the secondary for the first six LISs and the primary for the other six LISs. The resulting configuration will have 12 LISs, six being served by one device, and six being served by the other. If either device goes down, the other device will take over the server role for all 12 LISs.
It should be noted that there will be two ATM addresses associated with the ATM endpoint. One ATM address will be the real ATM address, and the other will be a special redundancy ATM address, called the redundancy address. The redundancy address is always registered. The redundancy channel is established between the primary's and secondary's redundancy addresses. The redundancy addresses are used for redundancy activity only. The real addresses are used for the exchange of IP information.
In ARP Server redundancy, when configured as a primary, the primary entity will always try to register its real ATM address until it is successful. The primary will also attempt to place a call for the Redundancy channel to the secondary.
Notes:
The following steps describe the ARP Server redundancy configuration process for a non-distributed ARP Server LIS:
| Note: | Please see the sample configuration provided in "Sample ARP Configurations" for more detail. |
ARP Server Redundancy provides the capability of a backup server for 1577 clients. 2225 clients do not need ARP Server Redundancy because they are capable of switching to a backup ARP Server.
The Distributed ARP Server allows you to maintain connectivity with a LIS in the event of an ARP Server failure. You can define as many distributed servers as you need per LIS (normally three to four are sufficient). The distributed servers can be located anywhere in your ATM network. They do not need to be meshed, but there must be some communication path from one to another.
An additional benefit of Distributed ARP Server is that the ATM ARP Service load can be distributed over many devices, allowing large LISs to be handled more efficiently.
Distributed ARP Servers on the same LIS must be configured with:
The Distributed ARP Server complies with the IETF draft "Server Cache Synchronization Protocol (SCSP) - NBMA." SCSP is the general-purpose protocol for distributing server databases over ATM networks.
ATM ARP clients must be able to recognize when their connection to the ARP Server is not operational and they must be able to switch to an alternate server. RFC 2225 compliant clients satisfy this requirement.
In Figure 50, two ARP Servers are defined on one LIS. These ARP Servers are configured so that they duplicate each other's ARP database. The SCSP in each device is configured with the SCSP ATM address of the other ARP Server. The ARP Servers establish a private session in order to exchange database information. The SCSPs in the device interact with the ARP Server in the same device to get and report cache changes.
The ATM ARP client is configured to have two ARP Servers, one as the primary and one as the backup in case of failure. If the client loses contact with the primary, it will register with the backup. The backup will have the full ARP resolution database and will provide ARP resolution service to the client.
Figure 50. Simple Distributed ARP Server Configuration
In Figure 51, three ARP Servers are configured on one LIS. Device 1 is configured with one Directly Connected Server (DCS), Device 2 is configured with two DCSs, and Device 3 is configured with one DCS.
Client 1 is configured with Device 1 as its ARP Server. Client 2 is configured with Device 3 as its primary server and Device 2 as its backup. With this configuration, Client 1 can get the address of Client 2 from Device 1 even though Client 2 is registered with Device 3. Likewise, Client 2 can get the address of Client 1 from Device 3.
If Device 3 fails, Client 2 can switch to Device 2 for ARP service with no loss of connectivity. If Device 1 fails, Client 1 will eventually lose connectivity with the LIS since it does not have a backup ARP Server configured. If Device 2 fails, redundancy is lost. In order for this configuration to retain full redundancy, the devices would need to be fully meshed.
Figure 51. Distributed Configuration with Three ARP Servers
The Distributed ARP Server allows you to provide alternate ARP server support for RFC 2225 clients. ARP Server Redundancy allows you to define a backup ARP server for RFC 1577 clients. The redundancy function and the Distributed ARP Server function can be defined on the same device. In this configuration, both primary and backup are defined as servers with SCSP enabled. When both are operating, they act as ARP servers with the full ARP database available. When the primary fails, the backup takes over the ATM address of the primary (and also keeps its own). Furthermore, if the backup fails, the primary can take over the ATM address of the backup and hence support its 1577 clients.
| Note: | Both primary and backup must be attached to the same ATM switch. |
Figure 52. ARP Server Configuration with RFC 1577 and 2225 Clients
A server can be configured as both a redundant server and a distributed server. In Figure 52, distributed ATMARP servers are used for LIS 9.1.1. Both Server X and Server Y are actively serving different sets of ATMARP clients on LIS 9.1.1. Server X is serving the RFC 1577 compliant client and Server Y is the first choice of the 2225 client. The databases of the two ARP Servers are synchronized by the SCSP protocol. If Server Y were to fail, the 2225 client would use the next entry on its list of ATMARP Server ATM addresses and connect to Server X.
In order to provide ARP Server redundancy for the 1577-compliant client, Server X is designated as the primary ARP Server for ATM address Prefix 1.ESI 1.Sel 1 and Server Y is designated as the backup ARP Server for ATM address Prefix 1.ESI 1.Sel 1. The primary and backup ARP Servers provide redundancy support. If Server X fails and Server Y takes over, Server Y will register the ATM address Prefix 1.ESI 1.Sel 1 in addition to its other ATM addresses. Thus Server Y will simultaneously represent ATM address Prefix 1.ESI 1.Sel 1 and ATM address Prefix 1.ESI 2.Sel 1. If Server X subsequently recovers and reestablishes the Redundancy VCC to Server Y, Server Y will deregister ATM address Prefix 1.ESI 1.Sel 1 so that Server X can resume its role as one of the active ARP Servers for the LIS.
Peer redundancy depends on the existence of the redundancy channel between the pair of Distributed ARP Servers configured for redundancy. The ATM client or server with the bigger redundancy ESI will initiate the redundancy channel with the partner. In this example, ESI 3 is greater than ESI 4, so Server X will initiate the call for the redundancy channel to Server Y.
When creating a new configuration for ARP Server Redundancy, peer redundancy is automatically enabled if the ATM Classical IP client is configured as a distributed ARP Server.
When an existing configuration is used from a previous release, peer redundancy is not automatically enabled. In this case, in order to enable peer redundancy, use the change redundancy command to provide the partner server ESI and selector to each of the distributed ARP Servers and write the configuration to the device. Peer redundancy will then be enabled as long as the redundancy ARP Servers are distributed ARP Servers.
When distributed ARP Service for a client is disabled by changing the client configuration for a given IP address and there is a redundancy configuration, peer redundancy will be disabled. You will be prompted to verify the redundancy configuration for correctness when the distributed ARP service is disabled.
The 2216 uses LLC/SNAP encapsulation as specified by RFC 1483 to carry IPX traffic over ATM. 2216s (and other routers that support RFC 1483 LLC/SNAP encapsulation on ATM) can be interconnected in full or partial meshes via manually configured RFC 1483 connections. Both PVCs and configured SVCs are supported. However, SVCs to IPX routers must be dedicated to IPX; they cannot be shared with other protocols, such as IP.
The 2216 supports a single IPX network per ATM interface. This implies a single ATM ARP client per interface for IPX which must be explicitly configured. Therefore, all interconnected routers on the ATM interface must be part of the same IPX network.
IPX ATM addresses must be unique among all components using RFC 1483 encapsulation (which includes Classical IP components). The ESI and the selector portions of IPX ATM addresses are configured in the same manner as Classical IP ATM addresses. If the 2216 is not initiating the SVC, then at least the selector should be explicitly specified in the current configuration to provide a fixed address that can be configured at the calling router.
IPX protocol addresses have two parts:
Network numbers must be unique within IPX routing domains, and host numbers must be unique within a given network. The IPX host number is set (by the 2216) to the ESI component of the associated ATM address. The ESI defaults to the MAC address burned into the ATM interface hardware in case that one is not explicitly configured by the user.
Destination IPX host numbers may be specified during VCC configuration or learned dynamically via InATMARP. You must manually configure the IPX host numbers of destination routers that do not support InATMARP. InATMARP is also used to periodically refresh the 2216's knowledge of a connected router's IPX host number.
Routers that are interconnected in a partial mesh and are providing intermediate routing between routers on the same ATM interface should disable IPX split-horizon on the ATM interface. This ensures RIP and SAP properly inform the interconnected routers of all available routes and services. Routers that are interconnected in a full mesh need not disable split-horizon.
Using the ATM Virtual Interface facility, IPX is no longer limited to one address per physical ATM interface. Several ATM Virtual Interfaces can be defined on a physical ATM interface and one IPX address can be configured on each ATM Virtual Interface.
Refer to the Nways Multiprotocol Access Services Software User's Guide for additional information about ATM Virtual Interfaces.
Although bridging does not use ARP support, the implementation of bridging over native ATM shares some internal structures with ARP. In this relationship, ATM client and channel records for bridge ports may be displayed and modified (client record only). Note that addition and deletion of these records is done automatically when a bridge port is added or deleted on an ATM interface.
For more details on RFC 1483 support for bridging over ATM, please see "RFC 1483 Support for Bridging".